INTEGRATED SYSTEMS FOR ELECTRONIC BILL 
PRESENTMENT AND PAYMENT 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This patent application is a continuation of U.S. 
Patent Application No. 09/751,265, filed on December 29, 
2000, entitled "Integrated Systems for Electronic Bill 
Presentment and Payment, " the entirety of which is 
incorporated herein by reference. 

BACKGROUND OF THE INVENTION 
[0002] Field of Invention — The present invention 
relates generally to electronic commerce, and more 
particularly to methods and systems for integrating 
electronic bill presentment and payment among billers, 
consumers, banks and other financial institutions, 
electronic payment facilitators, and web portals and other 
spaces able to support an interface for presentment and/or 
payment of bills. 

[0003] Billing consumers for goods and services has 
always been a necessary exercise and transaction cost of 
engaging in credit-based commerce. Traditionally, 
businesses bill consumers for goods and services by 
generating and mailing paper bills or invoices. There are 
many obvious business concerns relative to paper-based 
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billing. Companies utilizing paper-based billing do so at 
a substantial cost. For example, a company with 100,000 
accounts which are billed on a monthly basis may spend over 
two million dollars a year in paper-based billing expenses. 
Much of this expense stems from the cost of materials, 
postage, and manual processing of the paper bills, inserts, 
and envelopes. 

[0004] Other significant logistical and business 
concerns detract from the paper-based billing option. The 
time delay associated with sending bills and receiving 
payments via conventional mailing deprive companies of the 
time value of money and therefore create additional 
transactional costs. This time delay is particularly 
troublesome to small billers and non-recurrent billers who 
tend to rely more heavily on cash flow. 

[0005] Paper-based billing can also deprive billers of 
an opportunity to build brand. Although many paper billers 
include various types of marketing inserts with their bills 
in an attempt to use the billing activity as an additional 
opportunity to make favorable brand impressions on the 
consumer, those materials cannot be targeted as effectively 
as in an interactive session. For instance, billers do not 
have significant realistic control over the circumstances 
under which, or whether, a consumer views particular 
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inserts. Indeed, studies have shown that many consumers 
disregard such inserts altogether. 

[0006] The development of the Internet creates new 
opportunities to transact business electronically, 
including to conduct the billing presentment and payment 
process electronically, in an on-line way or otherwise. 
Some refer to various aspects of the electronic billing 
process as electronic bill presentment and payment (EBPP) . 
Instead of mailing paper bills, EBPP enables businesses to 
publish, distribute and/or present bills electronically on 
web pages. Instead of writing checks and applying stamps, 
consumers have the opportunity to pay bills by an 
electronic credit card charge or direct bank draft. The 
biller benefits by avoiding the cost of generating and 
mailing paper bills, and by avoiding the payment float 
occasioned by two-way mail delay and other delays in paper- 
based remittance. The consumer benefits with the added 
convenience of conducting transactions online, and the 
opportunity to pay many or all bills on one site or in one 
virtual space. 

[0007] In practice, however, there are significant 
concerns with conventional approaches to EBPP. For example, 
in one common approach to EBPP, which is often referred to 
as the custom development method, billers create a 
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proprietary electronic billing system and link it to a 
third-party for payment processing. Because custom 
development is mostly an internal EBPP solution, it gives 
billers the advantage of tight control over the billing 
system. However, this type of solution is very costly. Not 
only is it a technology risk because billers lose the 
flexibility to adapt to other EBPP standards, but it 
requires a substantial amount of manpower and 
infrastructure. Furthermore, such systems innately 
discourage consumer use or popularity, since the consumer 
is required to log onto and initiate a session on a 
separate site for each different bill the consumer wishes 
to pay. 

[0008] A second common EBPP approach, which is referred 
to as the consolidator approach, presents its own set of 
problems. This method of enabling EBPP trades control of 
the billing interface and branding opportunity for a 
reduction in cost, risk, and internal staffing by 
outsourcing the EBPP to a third party consolidator. Here, 
the electronic payment processor takes on a lock box 
function of holding and moving cash during billing and 
payment. The payment processor performs an aggregation 
function by presenting multiple billers 1 statements at a 
single, consolidating web site. Not only does 
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interposition of the consolidator and its interface between 
billers and consumers interrupt any existing relationship, 
but it also precludes exploitation of new biller 
opportunities to interact with consumers. 

[0009] In addition to the problems already mentioned, 

existing EBPP enabling methods have various other 
disadvantages- For example, they remain an expensive 
option for most billers who lack sufficient economies of 
scale necessary to overcome the high fixed cost of 
implementation. These EBPP methods, which primarily focus 
on reducing biller costs, also often fail to address the 
issue of consumer convenience adequately, much less to 
provide effective incentives for consumer adoption/ 
[0010] Furthermore, conventional EBPP approaches, which 
seek to implement EBPP on portal interfaces, often require 
redundant resources supported by multiple entities and 
consequently waste processing and transport resources. For 
example, using existing EBPP methods, if a consumer desires 
to pay AT&T bills electronically at a website such as 
Yahoo.com, the following occurs. First, the consumer 
requests that Yahoo.com receive the AT&T bill and send it 
to the consumer. Then, assuming AT&T partners with an 
electronic payment facilitator such as CheckFree, Yahoo.com 
makes a request to CheckFree. Finally, CheckFree initiates 
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the request to AT&T. Because each of these entities are 
independent, each requires its own resident database and 
other support functionality. Such conventional portal- 
supported EBPP approaches provide significant opportunity 
for improvement . 

SUMMARY OF THE INVENTION 
[0011] The present invention provides fully integrated, 
end-to-end electronic bill presentment and payment systems. 
Such systems support integrated EBPP access and 
functionality for billers, consumers, banks, other 
financial institutions, and other electronic payment 
facilitators, any or all of which can be transacted at a 
web portal, web site or other interface or virtual space 
("Portal Interface") . Such systems can support such 
activities at multiple portals, so that consumers and 
others have the choice of paying bills and accomplishing 
other EBPP transactions in whatever virtual space or at 
whatever site they desire. The systems provide consumers, 
billers and others the ability to self-enable EBPP by 
interacting with the portal interface such as via a series 
of web pages. Such systems of the present invention can 
control all interactions between billers and consumers from 
the portal interface. In addition, the systems can 
seamlessly orchestrate all other transactions with payment 
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facilitators and banks. Therefore, all EBPP functionality 
and processes can be controlled by systems and processes 
according to the present invention. 

[0012] The Portal Interface controlled by systems of the 
present invention provides individual consumers with a 
secure personalized electronic bill portfolio where they 
can schedule, view, and pay their electronic bills. The 
Portal Interface controlled by such systems also enables 
billers to create consumer accounts and electronically 
publish their bills on a personalized electronic bill 
portfolio for viewing and payment. The systems can provide 
all bill processing, payment processing, consumer and 
biller data storage, and arrange all external billing 
transactions. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0013] Figure 1 is a block diagram showing external 
connectivity of a preferred embodiment of integrated 
electronic bill presentment and payment systems of the 
present invention . 

[0014] Figure 2 is a block diagram illustrating the 
architecture of a preferred embodiment of integrated 
electronic bill presentment and payment systems of the 
present invention. 

[0015] Figure 3 is a block diagram illustrating general 
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functionality of a customer-related portal interface 
supported by a preferred embodiment of integrated 
electronic bill presentment and payment systems of the 
present invention . 

[0016] Figure 4 is a block diagram illustrating general 
functionality of a biller-related portal interface 
supported by a preferred embodiment of integrated 
electronic bill presentment and payment systems of the 
present invention . 

[0017] Figure 5 is a sign in screenface of a portal 
interface generated by a preferred embodiment of systems of 
the present invention. 

[0018] Figure 6 is a help screenface of a portal 

interface generated by a preferred embodiment of systems of 
the present invention. 

[0019] Figure 7 is an inbox screenface of a portal 
interface generated by a preferred embodiment of systems of 
the present invention. 

[0020] Figure 8 is a bill summary list screenface of a 

portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0021] Figure 9 is a company list screenface of a portal 
interface generated by a preferred embodiment of systems of 
the present invention. 
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[0022] Figure 10 is an add a company screenface of a 
portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0023] Figure 11 is a my outbox screenface of a portal 
interface generated by a preferred embodiment of systems of 
the present invention. 

[0024] Figure 12 is a pay accounts screenface of a 

portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0025] Figure 13 is a preferences screenface of a portal 
interface generated by a preferred embodiment of systems of 
the present invention. 

[0026] Figure 14 is a change password screenface linked 

off the preferences screenface of a portal interface 
generated by a preferred embodiment of systems of the 
present invention . 

[0027] Figure 15 is a personal information screenface 

linked off the preferences screenface of a portal interface 
generated by a preferred embodiment of systems of the 
present invention. 

[0028] Figure 16 is payment reminder creation screenface 
linked off the preferences screenface of a portal interface 
generated by a preferred embodiment of systems of the 
present invention . 
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[0029] Figure 17 is a generic create a reminder 

screenface linked off the preferences screenface of a 
portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0030] Figure 18 is a contact customer service 
screenface linked off the preferences screenface of a 
portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0031] Figure 19 is a biller signup screenface of a 
portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0032] Figure 20 is a bill template design step 1 
screenface of a portal interface generated by a preferred 
embodiment of systems of the present invention. 
[0033] Figure 21 is a bill template design step 3 
screenface of a portal interface generated by a preferred 
embodiment of systems of the present invention. 
[0034] Figure 22 is a bill template design step 2 
screenface of a portal interface generated by a preferred 
embodiment of systems of the present invention. 
[0035] Figure 23 is an invoice creation step 1 
screenface of a portal interface generated by a preferred 
embodiment of systems of the present invention. 
[0036] Figure 24 is an invoice creation step 2 
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screenface of a portal interface generated by a preferred 
embodiment of systems of the present invention. 
[0037] Figure 25 is an invoice preview screenface of a 
portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0038] Figure 26 is a report builder screenface of a 
portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0039] Figure 27 is a reports screenface of a portal 

interface generated by a preferred embodiment of systems of 
the present invention. 

[0040] Figure 28 is an upload bills screenface of a 

portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0041] Figure 29 is bill quality assurance screenface of 

a portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0042] Figure 30 is a second bill quality assurance 

screenface of a portal interface generated by a preferred 
embodiment of systems of the present invention. 
[0043] Figure 31 is a third bill quality assurance 
screenface of a portal interface generated by a preferred 
embodiment of systems of the present invention. 
[0044] Figure 32 is an add an account screenface of a 
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portal interface generated by a preferred embodiment of 
systems of the present invention. 

[0045] Figure 33 is a send customer e-mail screenface of 

a portal interface generated by a preferred embodiment of 
systems of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 
[0046] Figure 1 shows connectivity of a preferred 

embodiment 10 of integrated electronic bill presentment and 
payment systems ("systems") of the present invention. 
System embodiment 10 interfaces with, among other external 
entities, billers 12, which may include very small and non- 
recurrent billers 14, banks and other financial 
institutions 16, payment facilitators 18, web portals and 
bill presenters 20, and consumers 22. System embodiment 10 
shown in Figure 1 is implemented on a Sun platform using an 
Oracle database with other programs that allow connectivity 
via any desired network or transport infrastructure, 
preferably the Internet, to a portal interface in spaces 20 
via an Extensible Markup Language or other standard markup 
or other common data interchange model or language. Portal 
interfaces 15 may be implemented in Hypertext Markup 
Language or as otherwise desired to operate on browsers, 
whether or not applet enabled, or as otherwise desired. 
[0047] Figure 2 shows an architecture diagram for a 
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preferred embodiment 10 of systems according to the present 
invention. System embodiment 10 supports a portal interface 
15 which allows consumers 22 and billers 12 and/or 14 the 
ability to self-enable EBPP by interacting with a series of 
web pages or other interfaces or presentations of whatever 
desired design or type on a web portal 20 or at any other 
location in actual, electronic or virtual space, supported 
by the global information infrastructure, successor 
systems, private systems or any other communications 
network or system. System embodiment 10 can enable all EBPP 
functionality via the portal interface 15. System 
embodiment 10 can control all interactions or transactions 
between billers 12 and/or 14 and consumers 22 using portal 
interface 15 as the communications and/or presentation 
medium. System embodiment 10 can also arrange all other 
necessary transactions with payment facilitators 18 and 
banks 16. 

[0048] System embodiment 10 may be created to allow 
consumers 22 to define whatever portal or any other 
location or space they desire to access system embodiment 
10. This can be any web portal 20 or other bill presentment 
web site, such as Yahoo.com® or G02Net®. In order to 
initialize a bill portfolio, consumers 22 can go to the 
selected web portal or other space 20. System embodiment 10 
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prompts consumers 22 for personal information sufficient 
for authentication. System embodiment 10 can be adapted 
only to assign consumers 22 a secure bill portfolio when 
consumers 22 can be authenticated by a third party credit 
reporting agency. After being verified, a consumer bill 
portfolio may be access controlled by any desirable schema 
or paradigm, including by using a bill portfolio 
identification number, a unique consumer identification 
number, and an encryption key defined by consumers 22. 
Consumers 22 may also define multiple accounts at the same 
bill portfolio. 

[0049] Figure 3 illustrates the general functionality of 

a preferred embodiment of a consumer portal interface 
supported by system embodiment 10. System embodiment 10 
provides consumers 22 a secure personalized portfolio for 
viewing and paying electronic bills that are input into 
system embodiment 10 by various billers. System embodiment 
10 directs all incoming electronic bills to the bill 
portfolio of consumers 22. Consumers 22 also have the 
option of notifying paper-based billers that they desire to 
have bills presented electronically. System embodiment 10 
can notify the billers and initiate electronic scanning of 
paper bills. Consumers 22 may access the portfolio at any 
location of choice using any interface, such as, for 
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instance, a conventional web browser, other online device, 
any wireless device, or any other device which may 
communicate with system embodiment 10 in any manner. Any 
such device is a candidate to support presentation of or 
transaction with portal interface 15 by consumers 22. 
Consumers 22 can also define the format of the billing 
information. For example, the billing data may be supplied 
to consumers 22 in a variety of standard accounting 
formats . 

[0050] System embodiment 10 also enables consumers 22 to 
pay electronic bills via credit card, ACH, or electronic 
funds transfer or using any other mode or medium of payment 
or reconciliation. System embodiment 10 can also support 
payments between different consumer bill portfolios. In 
addition, system embodiment 10 can provide for various 
types of communication between or among billers 12 and/or 
14 and consumers 22 and between or among consumers 22. 
[0051] Figure 4 illustrates the general functionality of 
a preferred embodiment of a biller interface in accordance 
with the present invention with system embodiment 10. 
Billers 12 and/or 14 may self-enable EBPP by accessing 
system embodiment 10. System embodiment 10 can obtain 
information from billers 12 and/or 14 and authenticate by a 
credit verifier service if desired. After a biller is 
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authenticated, system embodiment 10 enables billers 12 
and/or 14 to define the presentation of the bill, among 
other things. Billers 12 and/or 14 may also do such things 
as customize bill templates, upload logos, addresses, and 
define bill fields. System embodiment 10 may support 
billers 12 and/or 14 carrying out any desired or 
desirable task, such as specifying marketing messages that 
are defined by consumer specific rules, set up consumers 22 
to bill and/or set up specialized consumer groups based on 
predefined rules. 

[0052] Billers 12 and/or 14 can also specify various 
other bill generation criteria. The bill criteria can 
accommodate criteria such as whether the bill is for a 
fixed amount or whether it is formula based. Billers can 
also specify the bill schedule. 

[0053] Billers 12 and/or 14 may bill consumers 22 by 
inputting any bill data. System embodiment 10 enables 
billers 12 and/or 14 to predefine how the electronic bill 
is to be displayed. System embodiment 10 also manages the 
routing of the bills. System embodiment 10 selects the 
biller-def ined delivery channel, which could be either 
paper or electronic. If a bill portfolio exists, the bill 
is placed in it. If the billed consumer 22 does not have 
a bill portfolio, electronic deliveries can be sent via 
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email along with a message notifying consumer 22 that the 
biller is using electronic billing. If neither exists, 
system embodiment 10 can perform standard paper billing. 
System embodiment 10 may also enable billers 12 and/or 14 
to identify conventional mailing addresses for consumers 22 
so that consumers 22 may enable standard paper billing. 
System embodiment 10 may also provide notification to 
billers 12 and/or 14 when bills are rejected, bills are 
overdue, or payments are received. 

[0054] Figures 5-18 show web pages of a preferred 

embodiment of a consumer portal interface on a web portal 
20 controlled by system embodiment 10. As mentioned above, 
the interface 15 can appear on any device in any location 
in actual, electronic or virtual space, using any network 
or communications system; use of the web and browser 
paradigm for the following description is merely one 
example and should not be interpreted to limit the 
invention or its scope in any way. That said, figures 5 
and 6 show web pages for the initial welcome screens for a 
web portal 20 of system embodiment 10. As any other web 
site or web portal 20 on the Internet, the welcome screen 
and all linked web pages on web portal 20 are freely 
accessible to billers 12 and/or 14 and consumers 22 using 
any standard web browsing software and computer. Consumers 



MW\1034827ATP:DMM 11/12/03 



17 



22 may also access the web pages by using any device of 
whatever stripe, such as a personal digital assistant, a 
cellular phone, or pager, which supports Internet access 
via wireless technology, standard telephone dial-up or 
network connections, or any communications system. 
[0055] The welcome screen permits new billers 12 and/or 
14 and consumers 22 to create a new account. When setting 
up a new account, billers 12 and/or 14 and consumers 22 are 
required to input personal information that can be used to 
identify and authenticate the user for subsequent sessions. 
After the user inputs the personal information, the system 
can contact a credit verifier company, such as Equifax® or 
TRW®, and uses a credit report supplied by the company to 
automatically determine whether the user meets certain 
predetermined requirements, in which case a new account may 
be created. 

[0056] After creating an account, the welcome screen 
permits new consumers 22 to create a new personalized bill 
portfolio or additional bill portfolios. Some sophisticated 
consumers 22 may desire to have separate bill portfolios 
within the same account for multiple homes, separate 
individuals within a home, or for a separate business. 
After a biller account is established, new billers 12 
and/or 14 may access the biller functionality, which is 
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discussed below. 

[0057] The welcome screen also permits billers 12 and/or 
14 and consumers 22 that have already registered to access 
system embodiment 10 by inputting a user identification 
number, a personalized password, and an encryption key. 
These user specific identifiers ensure that only registered 
users that have been authenticated are granted access to 
personal information stored on system embodiment 10. 
[0058] Figures 7-18 show a series of web pages for a 
personalized bill portfolio management system that 
registered consumers 22 use to access and interact with a 
bill portfolio via portal interface 15. Figure 7 shows an 
incoming bill web page that enables consumers 22 to 
interact with all incoming electronic bills including 
electronic bills that have been received but remain unpaid 
and paper bills that have been received and scheduled for 
electronic presentment. For each bill, the web page 
displays the biller's name, the amount due, the date 
payment is due, and the status of the bill. Consumers 22 
may also select and view each electronic bill. Figure 8 
shows a web page displaying a sample bill summary and 
payment information. The incoming bill web page also 
permits consumers 22 to select and electronically pay 
particular bills. 
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[0059] System embodiment 10 enables consumers 22 to 
notify paper billers that they desire to have bills 
presented electronically. System embodiment 10 can contact 
the paper-based biller and notify the biller that their 
electronic bills may be presented to consumers via system 
embodiment 10. If the biller declines, system embodiment 10 
can arrange to have the paper bill scanned into system 
embodiment 10 where it can be viewed and paid by consumers 
22 using system embodiment 10. Paper bills that have been 
received and are being processed for scanning and 
electronic presentment are displayed on the incoming bill 
web page as "scheduled". System embodiment 10 may also 
enable billers 12 and/or 14 to identify conventional 
mailing addresses for consumers 22 so that consumers 22 may 
enable standard paper billing. 

[0060] Figure 9 shows a biller list web page that 
enables consumers 22 to list the companies whose bills they 
desire to pay electronically. For each biller 12 and/or 14, 
the web page displays the company name, a corresponding 
identification number, and whether or not the company has 
been scheduled for electronic bill presentment and payment. 
Consumers 22 may also use the web page to modify the 
configuration for a biller 12 and/or 14 or to delete a 
biller 12 and/or 14 from the list altogether. Figure 10 
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shows a web page that enables consumers 22 to add 
additional billers 12 and/or 14 for electronic bill 
presentment and payment. The web page has a series of pull 
down menus' enabling a consumer 22 to define a biller 
configuration. One menu allows the consumer 22 to define a 
particular category for the biller 12 and/or 14. For 
example, consumers 22 may categorize billers 12 and/or 14 
as a utility biller, telecommunications service biller, 
credit card biller, professional services biller, or any 
other category of relevance to the consumer. Another menu 
allows the consumer 22 to select a bill delivery method 
such as CheckFree® or any other third party electronic 
payment facilitator 18. Other menus permit the consumer 22 
to input the account number for the biller 12 and/or 14, as 
well as an expiration date. Consumers 22 may also elect to 
enable functionality permitting a recurring payment 
schedule . 

[0061] Figure 11 shows an outgoing bill web page that 
enables consumers 22 to interact with electronic bills that 
have already been paid. Similar to the incoming bill web 
page, the outgoing bill web page displays the biller' s 
name, the amount due, the date payment is due, and whether 
or not the bill has been paid. Consumers 22 may also select 
and view a bill summary and payment information screen for 
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a particular bill. Finally, consumers 22 may select and 
delete bills that have already been paid. 

[0062] Figure 12 shows a payment accounts web page that 
enables a consumer 22 to view, add, modify, and delete 
credit card or debit card accounts that the consumer 22 
desires to use for electronic payment of bills. For each 
payment account the consumer 22 is required to input an 
account type, an account number, an account name, 
expiration date, and the name appearing on the card. 

[0063] Figure 13 shows a consumer preferences web page 
that enables the consumer 22 to personalize a bill 
portfolio. Figures 14 and 15 show web pages that enable 
consumers 22 to view and modify personal information 
associated with a bill portfolio and a personalized 
password for accessing a bill portfolio. The web page also 
enables consumers 22 to initialize email notification of 
when bills are presented to a bill portfolio for payment. 
Consumers 22 may also create generic reminders or bill 
payment reminders, which may be sent directly to an email 
address . 

[0064] Figures 16 and 17 show web pages for creating and 
scheduling generic reminders and payment reminders. The web 
pages enable consumers 22 to specify when the reminder will 
begin to be sent, how often the reminder will be sent, at 
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what time the reminder will be sent, and when to stop 
sending the reminder. For generic reminders, the consumer 
22 can be required to specify recipients of the reminder 
and the content of the message. 

[0065] At any time while logged into system embodiment 
10 and accessing a bill portfolio, consumers 22 may contact 
consumer service by using a consumer service web page as 
shown in Figure 18. The consumer service web page also 
lists a variety of contact information, as well as links to 
answers to frequently asked questions. 

[0066] The pages described above and shown in Figures 5- 
18 are merely exemplary. In a first sense, each or any of 
them may contain additional fields, or may contain fewer 
fields, to solicit or require information of any type or 
sort, or to allow consumers 22 to interact with system 
embodiment 10 in any way for the purpose or result of bill 
payment or reconciliation. In a second sense, other pages 
may be employed for such results or purposes, or any of the 
above-mentioned pages may be omitted. Again, these pages 
are merely one example of an embodiment of a portal 
interface that can support system embodiment 10 on any 
platform or device anywhere in actual, electronic or 
virtual space. 

[0067] Figures 19-33 show a series of web pages that 
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billers 12 and/or 14 may use to self-enable EBPP. (As 
mentioned above, the interface 15 can appear on any device 
in any location in actual, electronic or virtual space, 
using any network or communications system; use of the web 
and browser paradigm for the following description is 
merely one example and should not be interpreted to limit 
the invention or its scope in any way.) Any type of 
biller 12 and/or 14 may use system embodiment 10 to self- 
enable EBPP, but it is particularly advantageous to billers 
14 with a relatively small number of consumers, as well as 
billers 14 with non-recurring consumers. Figure 19 shows a 
registration web page for signing up to use system 
embodiment 10 for EBPP. Billers 12 and/or 14 can enter a 
series of information text boxes on the web page, which 
include a merchant identification number. System 
embodiment 10 can then contact' a credit verifier and access 
a credit report supplied by the credit verifier to 
automatically determine whether the biller 12 and/or 14 is 
authenticated. If the biller 12 and/or 14 is authenticated, 
system embodiment 10 automatically notifies the biller 12 
and/or 14 and access to system embodiment 10 is granted. 
[0068] As described above, once registered and 
authenticated billers 12 and/or 14 may access system 
embodiment 10 by inputting a user identification number, a 
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personalized password, and an encryption key. Figures 20 - 
22 show web pages that enable billers 12 and/or 14 to 
define the layout of an electronic bill. Figure 20 shows a 
web page for choosing a predefined template provided by 
system embodiment 10. Figure 21 shows a web page that 
enables billers 12 and/or 14 to interactively design their 
own bill template. Once the layout of the bill is defined, 
billers 12 and/or 14 can specify what type of software 
program they will use to provide consumer billing data to 
system embodiment 10. In the preferred embodiment of the 
invention, system embodiment 10 supports billing data of 
any type, such as, for example, data formatted to comply 
with over the counter software accounting packages such as 
QuickBooks® and Peachtree®, or billing data formatted as a 
printer datastream or a database export. Figure 22 shows a 
web page for billers 12 and/or 14 to select the appropriate 
billing data format. 

[0069] In situations where creating a bill template is 
not manageable, as for one time transactions with a 
consumer 22, system embodiment 10 can enable billers 12 
and/or 14 to send a one time only invoice. Figures 23 - 25 
show web pages that enable this functionality. Billers 12 
and/or 14 can be required to include the biller's name, the 
amount due, a description of the goods or services, the 
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recipient of the invoice, the number of the bill portfolio 
where the invoice is to be sent, and the date payment is 
due. After inputting the required invoice information, 
system embodiment 10 preferably permits the biller 12 
and/or 14 to preview the invoice as it will appear in the 
consumer's bill portfolio and send it. 

[0070] System embodiment 10 can also enable billers 12 
and/or 14 to create various reports. Billers 12 and/or 14 
may create reports showing any of a number of transactional 
statistics, such as the number of bills paid, the number of 
bills sent, the number of bills disputed, the number of 
bills partially paid, the number of bills published, the 
number of bills not published, and/or the number of bills 
that have been reviewed for quality assurance. Figures 2 6 
and 27 show web pages enabling billers 12 and/or 14 to 
create and schedule reports. 

[0071] System embodiment 10 can also enable billers 12 
and/or 14 to upload bills from a consumer's bill portfolio. 
Figure 28 shows a web page that enables billers 12 and/or 
14 to do this. Billers 12 and/or 14 may search for a 
particular consumer 22 by name or may sort for a number of 
consumers 22 in a predefined group. System embodiment 10 
performs the requested query and then displays each of the 
bills in the consumer's bill portfolio that are associated 
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with the biller. Billers 12 and/or may also select and 
preview a particular bill. Figure 29 shows a web page for 
previewing the bill of consumers 22. From the preview 
screen, billers 12 and/or 14 may edit the bill, send the 
bill, or defer sending the bill until later. Figure 30 
shows a web page that enables a biller 12 and/or 14 to edit 
a consumer's bill. 

[0072] As shown in Figure 31, system embodiment 10 can 
also enable billers 12 and/or 14 to add, modify, or delete 
consumer accounts. Billers 12 and/or 14 may add a consumer 
account or choose the account organizer by selecting the 
appropriate link on the web page. Figure 32 shows the 
linked web page where a biller 12 and/or 14 may input a new 
client's name, account number, email address, and 
attribute. System embodiment 10 may also enable billers 12 
and/or 14 to identify conventional mailing addresses for 
consumers 22 so that consumers 22 may enable standard paper 
billing. The attribute field can be used in combination 
with the account organizer to define groups of consumer 
accounts to simplify bill generation and delivery. Billers 
12 and/or 14 may use consumer groups to define and generate 
bills without the need for repetition. For example, when 
creating a list of consumer accounts, a biller 12 and/or 14 
may assign a specific zip code attribute to a group of 
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accounts, which would enable the biller 12 and/or 14 to 
generate and deliver all bills of the specific zip code at 
the same time. 

[0073] As shown in Figure 33, at any time while logged 
into system embodiment 10 billers 12 and/or 14 may send 
emails to a consumer's bill portfolio. Billers 12 and/or 
14 can use this functionality for payment reminders, 
marketing notices and offers, or any other advantageous 
use . 

[0074] The pages described above and shown in Figures 
19-33 are merely exemplary. In a first sense, each or any 
of them may contain additional fields, or may contain fewer 
fields, to solicit or require information of any type or 
sort, or to allow billers 12 and/or 14 to interact with 
system embodiment 10 in any way for the purpose or result 
of bill presentment or to effectuate payment or 
reconciliation. In a second sense, other pages may be 
employed for such results or purposes, or any of the above- 
mentioned pages may be omitted. Again, these pages are 
merely one example of an embodiment of a portal interface 
that can support system embodiment 10 on any platform or 
device anywhere in actual, electronic or virtual space. 
[0075] The foregoing is provided for purposes of 
disclosure of a preferred embodiment of the present 
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invention. Additions to, deletions or omissions from, or 
changes to interfaces, systems, or embodiments disclosed 
above may be accomplished; so long as they help carry out 
the results or purposes of providing systems that support 
interfaces to effectuate EBPP, they remain within the scope 
or spirit of the invention. 
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